前言：在之前的文档中，我们介绍过 secret 的使用，与其同类型的资源还有 configmap ，这里我们会简单介绍一下configmap， 以及分析 cofigmap 和 secret 在功能 和 使用场景上的区别。

ConfigMap 是有 key-value 类型的键值对，通过 ConfigMap 你可以将配置和运行的镜像进行解耦，使得应用程序有更强的移植性。

你可以通过控制台的 Kubectl 工具创建对应的 ConfigMap 对象，然后可以通过挂载数据卷、环境变量或在容器的运行命令中使用 ConfigMap。

我们可以通过两种方式来创建 ConfigMap：

From Literal Values和From Configuration File；

From Literal Values 方法：

我们可以用 kubectl create 来创建一个 ConfigMap，然后通过 kubectl get 来获取：

From Configuration File 方法：

除了上面的方式，我们还可以直接通过配置文件来创建（好吧，虽然我感觉是同一种，只不过是放到文件里面了而已……），首先，我们得有一个配置文件，假设名字叫做 myconfigmap.yaml：

然后，我们可以通过 kubectl create -f 来创建：

跟 secret 一样，configmap 可以在环境变量中使用，也可以作为数据卷挂载使用。

针对TKE 环境中的用法，可以参考：

https://cloud.tencent.com/document/product/457/31717

其实目前 Secret 的实现，就是 ConfigMap 把 value 用 base64 encode了一下，所以，其实不存在任何安全性，只要 decode 一下就能出现原来结果，相当于明文存储。

base64 这玩意儿都不能叫做加密，只能叫做编码，所以我们都不说 encrypt，而是 encode 和 decode。

当然，Kubernetes 社区有在计划对 Secret 进行下一步的安全性增强，当然这是后话了，截止目前为止，Secret 基本和 ConfigMap一样是明文存储。

理论上来讲，secret 和 configmap 可以在相同的场景下使用，因为功能上都是一样的。

这里结合生产环境看下当前主流的用法：

configmap：mysql redis 等涉及密码初始化类容器业务 （如MYSQL_ROOT_PASSWORD）

secret：第三方镜像仓库凭证 配置TLS 类型secret 用于记录证书秘钥等信息。